經歷了需求訪談、設計、系統開發與測試，專案終於要上線了。系統功能穩定、流程設計流暢，身為 PM 的你滿心期待能為客戶團隊解決問題並協助達到效率提升。
但當你去業務拜訪時，卻偶然聽到使用者小聲聊天說：「那個新的簽名系統看起來好麻煩，我還是比較習慣直接用紙本蓋章、寄快遞。」

這句話，無疑是所有 PM 最不希望聽到的話之一，也是專案中最常影響成敗的因素。它就是人性對於改變的本能抗拒。

改變不是一次推動，而是一段陪伴

如同上面的故事，在系統導入的專案中，最常遇到的不是功能做不出來，而是使用者不想用。畢竟決策者跟使用者往往是不同人。

這種抗拒是來自於：

• 對新事物的不信任
• 對學不會的焦慮
• 對改變工作習慣的不適

面對這種狀況，PM 的角色便不再是任務管理者，而是協助改變的陪跑員。我們不是只單站在終點揮手、大喊，而是願意陪使用者一起邊跑邊休息、跌倒時扶他起來並且解釋問題點的人。
下面就來說說，我自己遇到這種狀況的習慣作法。

1. 先講「為什麼」，而不是「怎麼用」

如果在教育訓練時，劈頭就進入功能介紹，很多人馬上就恍神了。我的習慣是一開始會先用「他們聽得懂的語言」，去解釋為什麼這系統會讓他們工作更輕鬆省力。

例如像這樣舉個實際的例子，讓他們有帶入感：
「大家現在是不是為了簽一份合約，要來回跑很多處室、找到經理或需要簽名的人，還有可能遇到要找的人請假、或是文件一直被壓在他那邊的狀況。好不容易簽完名，還要整理、掃描或 key-in。我們今天要導入的這個電子簽署流程，就是要來解決這些問題，讓你可以坐著就把文件跑完。」
「也就是說，我們今天不是要多學一個東西，而是以後遇到簽名文件時候，都可以少做五件事。」

先讓使用者理解原因，讓他們認同，他們才會願意學習改變。

2. 降低學習門檻

以下是我在撰寫操作手冊或功能教育訓練簡報時常用的幾個作法：

• 圖多字少，精簡步驟
  與其寫一堆字，不如放上幾張截圖，加上少量文字說明；讓使用者實際看到畫面，更能連結到實際操作的狀態。
• FAQ 放最前面
  大家來上課時一定心裡早就有很多問題，所以我習慣在最開始就會整理出一些最常見或最常被問的問題，在開始前先解答，來安定使用者的情緒。
• 用使用者會問的問題來設計
  用「使用者情境」來分類教學段落，而不是系統功能邏輯，例如：
  • 要寄出一份合約的操作流程
  • 怎麼確認對方簽了沒
  • 簽錯要重簽時怎麼辦
  • 文件簽完要作廢該怎樣操作

3. 找到願意嘗試的人，讓他成為你的盟友

使用者當中一定會有幾個心態開放、學得快的人，可以嘗試去找出他們，讓他們成為用戶端的「超級使用者」。這些人比我們這種外來的 PM 更了解他們的內部文化，更能知道實際的使用情境以及可能卡關的地方。
所以觀察到有這種角色時，我通常會做這些事：

• 在教育訓練後私下多問一句：「還有沒有地方覺得卡卡或疑問的？」
• 請他觀察有誰比較排斥，可能的話也進行協助。如果他們能私下溝通，通常會比我自己發聲來的有效。

一般來說，專案完成的定義會是指交付驗收然後上線；但我其實最怕看到的，是使用者在導入完成後幾乎沒在使用。因此，我通常會關注後續的使用者採納率 (Adoption Rate)，去當成我自己心目中衡量專案是否真正成功的 KPI。

關於專案中人的討論，就先到這底告一段落。明天，我們一起來做個第三週總結回顧 (雖然因為分配的關係，這週多一天哈哈)，讓我們將一個專案從誕生到使用者上手的歷程來做個總結。